home *** CD-ROM | disk | FTP | other *** search
/ Amiga Format CD 41 / Amiga Format CD41 (1999-06)(Future Publishing)(GB)[!][issue 1999-07].iso / -seriously_amiga- / emulation / anes / tech / mappertrace.doc next >
Text File  |  1999-04-19  |  2KB  |  51 lines
  1.  
  2. Mapper trace
  3. ------------
  4. Here is a small description of the "Mapper-trace" feature
  5. that is implemented in A/NES v0.99.99.
  6. Don't bother reading this unless you know exact what you're
  7. doing.
  8.  
  9.  
  10. Ever stumbled upon another rare-ROM with a really weird mapper-number
  11. and which doesn't even work in any emulator?
  12. Well then this feature is for you all NES-"hackers". :)
  13. When A/NES detects a non-supported mapper number, this feature is
  14. activated (if selected of course).
  15. All writes between $8000-$FFFF(which MMC's usually write) are trapped 
  16. and saved into a special log-file (RAM:ANESdebug.trc currently). 
  17. This allows the user later to check what the game did before it 
  18. crashed (ROMs with unknown mapper numbers usually crash sooner or later).
  19. Here is a short description of the debug-file (pro's only!):
  20.  
  21. The file is currently limited to 32-writes because logging all writes
  22. could probably result in several megabytes of data in just a few
  23. seconds (for ROMs that perform CHR-ROM swap several times/frame).
  24.  
  25. The file starts with a 16-byte header:
  26.  
  27. Offset: 0  -  8 = 'ANESTRACE' file identification
  28.               9 = This contains a version number that tells which
  29.                   version of A/NES that created this file (currently 99).
  30.              10 = Mapper number
  31.              11 = Number of PRG-ROMs in current ROM.
  32.              12 = Number of CHR-ROMs in current ROM.
  33.              13 = Number of "illegal writes" saved (currently 32)
  34.              14 = Empty
  35.              15 = Empty
  36.  
  37. Then follows the data structure. Each "illegal write" between $8000-$FFF
  38. consists of chunks of 8-bytes each, which looks like this:
  39.  
  40. Offset: 0  -  1 = Current scanline
  41.         2  -  3 = Which address?
  42.         4  -  6 = Empty
  43.               7 = Data to be written
  44.  
  45. The current scanline is stored because with it you could easily(?) detect
  46. if there is a possible bank-swap in the middle of the screen (for changing
  47. graphics for example) and it helps figuring out the MMC hardware.
  48.  
  49.  
  50.  
  51.